Designed and tested four competing ways to let customers pick a cash loan amount and repayment plan for a leading asset-financing fintech operating in Kenya and Nigeria — then ran moderated research across both markets to find out which one actually worked.
The production cash-loan flow asked customers to pick an amount, then tap through to see what they'd actually pay back. It worked, but we suspected the mental model was backwards — most customers already know what they can afford per day, not how much they want to borrow in the abstract.
I designed four competing interaction models for choosing an amount and repayment plan, plus an affordability-first flow that flips the opening question from "how much do you want?" to "what can you pay per day?" — then ran research in both Kenya and Nigeria to see which actually held up with real borrowers.
Rather than guess, I built four working prototypes of the same decision — choosing a loan amount and repayment plan — each testing a different interaction model, plus the existing production flow as a baseline.
Amount chips up front; tapping one reveals repayment options. All eligible amounts visible before any interaction.
One plus/minus control adjusts the amount live; term and daily payment update as you go.
Two independent live controls — amount and daily payment — adjustable at once.
A single preset amount shown by default, with the full list of eligible amounts collapsed behind a dropdown.
Every amount-first variant asked the same opening question — how much do you want to borrow? — and left customers to work out whether the repayment was affordable. But across both markets, the number people actually reasoned from wasn't the loan size. It was the daily payment: "I prefer 94 shillings per day," "I will check if I can pay fast to see the amount I have to pay daily."
So I prototyped a fifth direction that flips the question: start with "what can you comfortably pay?", then surface only the loans that fit that budget. I built it two ways — a single live screen that filters offers as you set a daily figure, and a guided step-by-step version that walks first-time borrowers through budget, then amount, then confirmation.
Set what you can pay per day and the eligible loans filter live beneath it — no separate amount step.
Budget first, then amount, then confirm — scaffolding for first-time and less confident borrowers.
Pick one of the five flows, choose a market (Kenya or Nigeria), then tap the M-KOPA app icon on the phone's home screen to launch it — just as participants did in testing. The All flows icon returns you here to try another.
Moderated in-person usability interviews combined a borrowing-history intake with a prototype comparison — sequential monadic, with each participant shown a rotating subset of three variants to keep sessions short while preserving comparability across the full set.
The strongest option differed by market — but the two-knob variant lost everywhere, badly enough to rule out outright.
Amount + daily (two-knob) scored worst in both markets — SEQ 4.44 in Kenya, and a 0% task outcome rate in Nigeria. Two live numbers on one screen didn't give users more control; it gave them a contradiction they couldn't resolve.
Every variant that hid the eligible amounts behind a stepper, a live knob, or a collapsed dropdown caused the same failure: users assumed the first number shown was the only amount they qualified for.
"I only thought I qualified for KES 15,000 and not more."
Across every Nigerian prototype, participants mistook the repayment term in days for the loan amount in Naira — because the two numbers share a similar numeric range. One participant picked "180 days" and called it "NGN 180,000."
In both markets, participants volunteered — without being asked — that fully-visible layouts would be easier for less tech-savvy or less literate users. They picked different variants for the reason, which elevated it from a preference to a design principle.
Advance Filter by Amount for Kenya and Amount Only for Nigeria into design refinement. Drop the two-knob variant entirely.
To keep the test a fair comparison, only the amount-selection step differed between variants — everything after it was identical. Once a customer had chosen their loan, all five flows funnelled into the same review-and-confirm screen and the same disbursement success screen. Holding these steps constant meant any difference in how well people understood their loan could be traced back to the one thing under test: how they picked the amount.
Every variant ended on these same two screens, so comprehension differences could only come from the selection step above.
Amount, daily payment, term and total laid out for the customer to check before agreeing.
Disbursement confirmed — the same closing screen no matter which selection model got the customer here.
I designed and built these flows in partnership with Claude. Rather than clicking through static Figma frames, I described each interaction model and iterated on real, working code — live steppers, chips that filter offers in real time, two knobs recalculating against each other, a dropdown that actually opens. The kind of behaviour that only reveals its problems when a user can genuinely touch it.
That fidelity mattered. The core finding — that Nigerian users mistook the repayment term for the loan amount — only surfaced because the prototype responded like the real thing. A tap-through Figma mockup would have hidden it. We then deployed each build to Netlify as an installable web app, so moderators ran the sessions on participants' own phones, full-screen, indistinguishable from production.
Working this way let me spend my judgement where it counts — on the interaction models, the research design, and reading the findings — instead of on redrawing frames. It's how one designer took five competing directions from idea to field-ready in five days.
The research pointed to two directions worth backing: Amount only (single knob) and Dropdown. Both were refined into production builds and are now being rolled out as an A/B test against the current live experience — Flow 1 (Today) — so the final call is made on real behaviour at scale, not just moderated sessions.
The two shipped screens are embedded below, exactly as they went out.
The single-knob build that went to production.
The dropdown build that went to production.
The A/B test is live and results are still coming in — this section documents recent work and process rather than a final outcome. I'll update it with the winning variant and its metrics once the experiment concludes.